home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / comm / clink120.zip / SEALINK.DOC < prev   
Text File  |  1987-08-24  |  14KB  |  361 lines
  1.                                      SEALINK
  2.  
  3.                              File Transfer Protocol
  4.  
  5.                                  August 24, 1987
  6.  
  7.  
  8.  
  9.             Copyright 1986,87 by System Enhancement Associates, Inc.
  10.  
  11.  
  12.  
  13.      This  document  describes  briefly  the SEAlink file transfer protocol
  14.      developers' package.  SEAlink is a sliding  window  protocol  that  is
  15.      fully backwards compatible with XMODEM in all tested implementations.
  16.  
  17.      The intent of SEAlink is to provide a file transfer protocol that does
  18.      not  suffer  from  propagation  delays,  such  as  are  introduced  by
  19.      satellite relays or packet switched  networks,  while  retaining  full
  20.      compatibility with XMODEM.  Unlike other high-speed protocols, SEAlink
  21.      does not "side step" to avoid using XMODEM,  but instead works with an
  22.      XMODEM driver to establish the fastest possible  link,  thus  reducing
  23.      startup delays in both SEAlink and XMODEM transfers.
  24.  
  25.      Actual  tests  of  the  enclosed  routines  has  shown that SEAlink is
  26.      capable of virtually eliminating  propagation  delays  and  turnaround
  27.      delays.  File transfers between New Jersey and Hawaii,  which normally
  28.      suffer a degradation of 50% or more due to satellite  relays,  proceed
  29.      as  fast as local transfers.  Even transfers within the local exchange
  30.      are speeded up by up to  20%  at  2400  baud  by  the  elimination  of
  31.      turnaround delays.  Large volume tests show that SEAlink is capable of
  32.      coming to within 2% of the theoretical minimum time for data transfer.
  33.  
  34.  
  35.  
  36.      The developers' package contains the following files:
  37.  
  38.          SEALINK.DOC    This document.
  39.          SEALINK.C      A set of C routines for implementing SEAlink.
  40.          CLINK.EXE      A sample TTY program that implements SEAlink.
  41.  
  42.  
  43.  
  44.      You are granted a license to use this code in your  programs,  and  to
  45.      adapt  it to your particular situation and needs,  subject only to the
  46.      following conditions:
  47.  
  48.       1) You  must  refer to it as the SEAlink protocol,  and you must give
  49.          credit to System Enhancement Associates.
  50.  
  51.       2) If you modify it in such a way that your version  cannot  converse
  52.          with the original code as supplied by us, then you should refer to
  53.          it as "SEAlink derived", or as a "variation of SEAlink",  or words
  54.          to that effect.
  55.  
  56.      In  short,  we're not asking for any money,  but we'd like to get some
  57.      credit for our work.
  58.  
  59.  
  60.  
  61.      This document is  not  meant  to  be  a  rigorous  definition  of  the
  62.      protocol.  The  code provided should serve to document the details and
  63.      fine points of implementing  SEAlink.  We  will,  however,  present  a
  64.      brief synopsis of how SEAlink adds sliding windows to XMODEM,  and why
  65.      XMODEM doesn't mind.
  66.  
  67.      First of all,  SEAlink adds a block number to the ACK and NAK used  in
  68.      XMODEM.(1)  We  thus  create  "ACK/NAK  packets",  with  the following
  69.      structure:
  70.  
  71.          Byte 0:   ACK, NAK, or C
  72.          Byte 1:   Block number
  73.          Byte 2:   One's compliment of block number
  74.  
  75.      This is identical in form to the first three bytes of a  data  packet,
  76.      except that the SOH has been replaced with an ACK or NAK.(2)
  77.  
  78.      From  the  receiver's point of view,  it does not matter if the trans-
  79.      mitter is using sliding window or not.  The receiver simply sends  ACK
  80.      and NAK packets as appropriate.  Any XMODEM driver tested to date will
  81.      simply ignore this excess data behind the ACK or NAK.
  82.  
  83.      From  the  transmitter's point of view,  it just barely matters if the
  84.      receiver can handle sliding window.  The transmitter always acts as if
  85.      it is sending sliding window,  but varies the window size.  If  it  is
  86.      seeing  valid  block numbers and check values behind the received ACKs
  87.      and NAKs,  it sets the window size to six blocks.  Otherwise,  it sets
  88.      the  window  size  to  one  block.  The  result is that it only "sends
  89.      ahead" if the receiver can handle it.
  90.  
  91.      It should be a fairly simple matter to apply  the  underlying  SEAlink
  92.      logic to almost any variant of XMODEM.
  93.  
  94.  
  95.      The  SEAlink  routines  provided  in  this package are also capable of
  96.      passing system dependent information,  such as true file size and time
  97.      of  last modification.  This data is passed in a special header block.
  98.      The header block looks exactly like any other block, except that it is
  99.      block number zero.
  100.  
  101.      This is still backwards compatible with XMODEM,  as a SEAlink receiver
  102.      does  not  mind if block zero is missing,  and any XMODEM receiver yet
  103.      tested will regard block zero as a duplicate block and ACK it.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.      (1) XMODEM/CRC uses a "C" in place of a  NAK  to  indicate  CRC  error
  117.          detection.  SEAlink  follows this convention,  and supports either
  118.          checksum or CRC.  For brevity, this document will use the term NAK
  119.          to mean either a true NAK (hex 15) or a C (hex 43).
  120.      (2) See previous footnote.
  121.      The data portion of block zero contains the following fields:
  122.  
  123.  
  124.          Offset    Size      Contents
  125.          ======    ====      ========
  126.  
  127.             0        4       Original file length.
  128.             4        4       Date and  time  file  was  last  mofified,  in
  129.                              seconds since 1979.
  130.             8       17       Original  file  name,  as  a  null  terminated
  131.                              string.
  132.            25       15       Name  of  transmitting  program,   as  a  null
  133.                              terminated string.
  134.            40        1       Overdrive flag.
  135.            41       87       Null filler and expansion area.
  136.  
  137.  
  138.      Any  field  which  the transmitter cannot support should be set to all
  139.      zeros.  Conversly,  the receiver should ignore any  null  fields.  The
  140.      receiver may ignore any field which he cannot support.
  141.  
  142.      Of special interest is the byte flag at offset 40 in block zero.  This
  143.      is  the  "Overdrive  flag",  and is used to trigger streaming mode for
  144.      high-speed,  half duplex modems.  In Overdrive mode the receiver stops
  145.      sending  ACKs  for  the  bulk of the file transfer,  thus facilitating
  146.      transfers over a half-duplex connection.  Overdrive is never  required
  147.      over a full duplex connection.  Overdrive requires that the basic link
  148.      be effectively error free.
  149.  
  150.      Overdrive is disengaged in either of the following conditions:
  151.  
  152.        o  The  transmitter will disengaged overdrive if it detects that the
  153.           receiver has dropped  out  of  overdrive,  or  does  not  support
  154.           overdrive.
  155.  
  156.        o  The   receiver  will  disengage  overdrive  if  it  finds  itself
  157.           receiving  an  excessive  number  of  bad  blocks,  as  Overdrive
  158.           requires an error-free link.
  159.  
  160.  
  161.  
  162.      The  routines  enclosed  in  this package should be reasonably easy to
  163.      implement in your application.  We have attempted to exclude  compiler
  164.      dependent and system dependent logic from these routines.
  165.  
  166.  
  167.      You  will need to alter our references to our communications driver to
  168.      conform to your own driver.  The communications  related  routines  we
  169.      use are:
  170.  
  171.          com_putc(c)         Output character c to comm port.
  172.  
  173.          int com_getc(t)     Get  character  from comm port within t tenths
  174.                              of  a  second.   Return  EOF  if  time   limit
  175.                              expires.
  176.  
  177.          com_dump()          Discard any pending output without sending it.
  178.  
  179.  
  180.  
  181.      In  addition,  we  use  the  following  routines for controlling timed
  182.      loops:
  183.  
  184.          long timerset(t)    Set a timer.  Returns a timer value which will
  185.                              expire in t tenths of a second.
  186.  
  187.          int timeup(z)       Check a timer.  Returns true if  timer  z  has
  188.                              expired yet, or false otherwise.
  189.  
  190.  
  191.      These  routines  also  make  reference  to the following function